An application program interface (API) gateway provides an intermediary between an API service and an API consumer that consumes the API service. One of the intermediary roles of an API gateway is to expose the API service to the API consumer and to control the traffic between the API consumer and the API service. Typically, the API service consists of a plurality of APIs, and each API has an endpoint that provides an entry to the API for the API consumer. An API gateway exposes each API endpoint by acting as a proxy for the respective API. An API gateway, or a grouping of API gateways, acts as a facade of endpoints for the API consumer to consume the service offered by each API. A typical consumption by an API consumer is a request to an API followed by a response by the API. The API gateway's facade of the API service enables the API gateway to receive requests from an API consumer for an exposed API, route requests to an appropriate API, route API responses to an appropriate API consumer, enforce security of each request, and perform traffic manipulation such as performing rate limiting on calls to an API.
In a typical API gateway architecture, a plurality of API consumers, such as devices, applications, and websites, are communicatively coupled to a set of API gateways in order to consume API services. The set of API gateways provide a facade for groupings of a plurality of API services, and each of the API services comprise at least one API. Each API gateway provides multitenant capabilities for groupings of API services. Such multitenant capabilities include load balancing strategies to route requests to one of a plurality of identical or similar API services.
The functionality of an API gateway is typically controlled by configuration data. In a traditional API gateway architecture, the configuration data of an API gateway is updated utilizing a release orchestration tool. A traditional release orchestration tool treats each API gateway as a node, and groups of nodes are updated in phases. The first group of nodes is traditionally updated as a canary release, i.e., a limited test release to ensure the update meets a quality standard and is functional within the first group of nodes. The first group of nodes that is traditionally updated by a traditional release orchestration tool allows for the detection of an update failure that, if present, is isolated to the first group of nodes acting as the canary. This canary release process avoids the massive failure that would have occurred if the update had been deployed to all the nodes at once.
However, with a traditional release orchestration tool, a development team that wishes to implement an update to the set of API gateways must wait for the release orchestration tool to implement a first phase canary release of the update. A typical release orchestration tool is a centralized tool operating apart from the set of API gateways, traditionally requiring a manual process to execute the release orchestration tool to make updates to API gateways. Traditionally, even if fifty or more updates were required in a day, such updates would be batch deployed once a day, typically at night, and that daily deployment would be considered fragile due to the release orchestration tool operating as a centralized tool apart from the API gateways. Further, the failures of the deployment of updates is indicative of the manual processing required to monitor a traditional release orchestration tool's deployment, indicating the fragility of a traditional release orchestration tool's operation.
Consequently, there is currently a significant need in the API services arts to provide for a self-orchestrated canary release deployment system and method within an API gateway architecture capable of decentralized deployment of API gateway updates in real-time manner, thereby providing a more efficient and robust API service provider system.